fix(pipeline): merge_to_main pushed HEAD, not the task's branch - #280

The worst one this session, because it reported success while doing nothing.

The bug

git push origin HEAD:refs/heads/main

…run from resolve_working_dir. That is the task's worktree when it has one, and the shared workspace checkout when it doesn't — which happens routinely, since terminal-column cleanup removes the worktree while branch_name survives on the row.

So HEAD was whatever the user happened to have checked out:

• Repo on main → HEAD:refs/heads/main is a no-op push that succeeds. The trigger then logs Pushed <branch> to origin/main having merged nothing.
• Repo on any other branch → it publishes unrelated working state to main.

Both are silent. The success log made the first actively misleading — I only caught it because I checked git ls-remote rather than trusting the log.

Reproduction, against a real bare origin

Before:

origin/main BEFORE: 9b5a20453ce8
[merge_to_main] Pushed kaitencode/feature-x to origin/main   ← the log
origin/main AFTER : 9b5a20453ce8                             ← unchanged
version.js on origin/main: NO

After:

origin/main BEFORE: 9b5a20453ce8
origin/main AFTER : d2e39ea4325c
version.js on origin/main: YES — merge landed

The fix

Push the task's branch by name — the same branch the function validates at the top and names in that log line. Extracted as merge_to_main_refspec so a test pins the one thing that must not regress (that it never names HEAD).

execute_auto_merge was checked for the same pattern and does not share it — it passes the branch name through explicitly.

Worth flagging separately

merge_to_main is backend-only: it's absent from the frontend ActionType union, so no UI can configure a column to use it. Noted on the roadmap rather than fixed here — that's a feature decision, not a bug fix.

Checks

cargo clippy -D warnings · cargo test --lib 569 (+1) · tsc · eslint · vitest 444.